• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    A method of synchronizing a first gateway of a LoRa network, to allow the first gateway to operate according to the LoRaWAN protocol class B communication mode. The method is based on at least one reception (50) of a synchronization frame by the first gateway, each synchronization frame having been transmitted (49) by a second class B gateway of the LoRa network, equipped with synchronization means and designated by a server. The first gateway uses a reception instant of each synchronization frame that it receives to synchronize (51) beacon transmissions, used in the implementation of the class B communication mode, with transmissions of beacons carried out by d. other class B gateways of the LoRa network.
    公开号:FR3047384A1
    申请号:FR1650688
    申请日:2016-01-28
    公开日:2017-08-04
    发明作者:Massinissa Lalam；Thierry Lestable
    申请人:Sagemcom Broadband SAS；
    IPC主号:
    专利说明:

    The invention relates to a method of synchronizing a gateway in a long-range wireless network and allowing low power consumption, devices and a system implementing the method. The Internet is gradually transformed into an extensive network, called "Internet of Things", connecting all kinds of objects, devices or terminals that have become connectable. New network requirements then emerged, including wireless network requirements with greater coverage than conventional cellular networks and limiting power consumption dedicated to connected equipment communications. Among these long range and low power Wide Area Network (LPWAN) wireless networks in English terminology are networks based on LoRa technology ("Long Range"). Anglo-Saxon terminology). LoRa technology operates in frequency bands known as the ISM Band (Industry, Science and Medical) with frequency bands that can be used freely for industrial, scientific and medical applications.
    A network based on LoRa technology (called "LoRa network" later) is composed of base stations or gateways ("gateways" in English terminology). The gateways are able to detect messages sent in their area by devices or terminals ("end-devices" in English terminology) and to trace them to at least one centralized server ("Central Network Server" in English terminology). ) who will treat them.
    In a LoRa network a terminal is not attached to a gateway. Each gateway within range of a terminal can thus serve as a relay between said terminal and the centralized server. If a gateway succeeds in decoding a message sent by a terminal (uplink), then it retransmits it to the centralized server for processing. If a message must be transmitted from a centralized server to said terminal (downstream), it is the centralized server that determines which gateway must relay the message. Each communication between a gateway and a terminal of a LoRa network as described above is done using a protocol called LoRaWAN. Like conventional cellular networks, several types of gateways can be envisaged. Gateways generally placed on high points, called macropasserelles, will cover a large geographical area. Other gateways, called femto-gateways, have a smaller geographical coverage, but are used to relay terminal communications in areas not covered by the macro-gateways, for example in buildings.
    In a LoRa network, each gateway periodically sends a signal called beacon ("beacon" in English terminology) so as to provide terminals supporting it (called class B terminals thereafter) a communication service ensuring a certain quality on duty. It is necessary that all tags issued by gateways in a LoRa network are synchronized with each other. Such synchronization is generally obtained by servoing each gateway (ie a clock of each gateway) on a reference signal, such as a GPS radio signal (global positioning system: "Global Positioning System" in English terminology). -saxonne). Such a synchronization solution requires, on the one hand, that each gateway has synchronization means such as means for decoding the synchronization signal (for example a GPS module), and on the other hand, that each gateway is in a position of being able to receive said synchronization signal.
    Most of the macro-gateways are equipped with synchronization means, generally using the GPS radio signal. However some macro-gateways can be, at least temporarily, out of range of a GPS signal. Moreover, it is not uncommon for femto-gateways deployed indoors are simply not equipped with synchronization means. Some gateways are therefore, at least temporarily, unable to synchronize through traditionally used LoRa network.
    It is desirable to overcome these disadvantages of the state of the art. In particular, it is desirable to propose a method enabling a gateway of a LoRa network, out of range of a reference radio signal of another technology or having no synchronization means, to synchronize in order to be able to transmit data. tags synchronized with beacons issued by class B gateways of the LoRa network.
    It is also desirable to provide a method that is simple to implement and low cost and in particular, does not require the addition of additional modules such as a GPS module in a gateway of a LoRa network.
    According to a first aspect of the present invention, the invention relates to a method of synchronizing a gateway of a long-range wireless network and allowing a low power consumption, intended to allow said gateway to operate in a mode Class B communication system, in which communication periods are defined from periodic beacon transmissions by each gateway of said network supporting said mode, said class B gateways, the beacon transmissions being synchronized between each class gateway B, each communication period being divided into a predefined number of sub-periods, a terminal of the network operating in said mode being able to bidirectionally communicate with a server via a Class B gateway only during a sub-period. period allocated to it. The method comprises, when implemented by a first gateway: transmitting to said server, via at least one second gateway of said network, a frame comprising a request for synchronization assistance; receiving a frame comprising information representative of a response to said request from a gateway of said network, called designated gateway, equipped with synchronization means, the designated gateway having been designated by the server among the at least one second gateway, receiving said frame allowing the first gateway to determine at least one communication period during which the first gateway must receive a frame, called synchronization frame, from the designated gateway; obtaining information representative of a sub-period of each determined communication period used by the designated gateway for transmitting a synchronization frame, said sub-period having a predefined deviation with a tag immediately following the communication period; receive at least one synchronization frame; and, for each received synchronization frame: determining from a time of reception of said synchronization frame and the predefined distance, at least one next moment of transmission of a beacon by each class B gateway of said network ; and transmitting a beacon at each next instant of determined transmission.
    In this way, the first gateway becomes, at least temporarily, a Class B gateway since it can transmit beacons synchronized with the beacons of other class B gateways of the network.
    In one embodiment, before transmitting the frame comprising a request for synchronization assistance, the first gateway checks whether at least one second gateway is in range to receive said frame and to transmit synchronization frames to the first gateway. , no frame including a request for synchronization help being issued if no gateway is in range.
    In one embodiment, following the transmission of the frame comprising the synchronization assistance request, if no response to said frame is received after a predefined duration, the first gateway renews its request for assistance with the synchronization. synchronization by issuing a new request frame for synchronization help.
    According to a second aspect of the invention, the invention relates to a method of synchronizing a gateway of a long-range wireless network and allowing a low power consumption, intended to allow said gateway to operate in a mode Class B communication system, in which communication periods are defined from periodic beacon transmissions by each gateway of said network supporting said mode, said class B gateways, the beacon transmissions being synchronized between each class gateway B, each communication period being divided into a predefined number of sub-periods, a terminal of the network operating in said mode being able to bidirectionally communicate with a server via a Class B gateway only during a sub-period. period allocated to it. The method comprises, when implemented by the server: receiving at least one request containing a request for synchronization assistance formulated by a first gateway and relayed by at least one second gateway; verify a feasibility of a synchronization aid, synchronization assistance being possible when at least one gateway among the at least one second gateway is equipped with synchronization means; when synchronization assistance is possible, designate a second gateway, designated gateway, equipped with synchronization means, to relay to the first gateway information representative of a response to the request for synchronization assistance, said information for setting up a transmission of at least one frame, referred to as the synchronization frame, by the designated gateway to the first gateway, in a predetermined sub-period of at least one communication period, each transmission of a synchronization frame enabling the first gateway to determine at least one instant of transmission of a synchronized beacon with beacon transmission times of each class B gateway of said network; and, transmitting a request including said information to the designated gateway.
    According to a third aspect of the invention, the invention relates to a method of synchronizing a gateway of a long-range wireless network and allowing a low power consumption, intended to allow said gateway to operate in a Class B communication system, in which communication periods are defined from periodic beacon transmissions by each gateway of said network supporting said mode, said class B gateways, the beacon transmissions being synchronized between each class gateway B, each communication period being divided into a predefined number of sub-periods, a terminal of the network operating in said mode being able to bidirectionally communicate with a server via a Class B gateway only during a sub-period. period allocated to it. The method comprises, when it is implemented by a second gateway of said network, the second gateway being of class B and being equipped with synchronization means: receiving a request from the server comprising information representative of a response to a request. request for synchronization assistance formulated by a first gateway, said request having been relayed by the second gateway to said server; transmit a frame comprising said response to the request for synchronization assistance to the first gateway, said response allowing the first gateway to determine in which sub-period of at least one communication period the first gateway must receive a frame of synchronization; and, transmitting at least one synchronization frame to the first gateway in said sub-period, receiving a synchronization frame in said sub-period allowing the first gateway to determine at least one transmission time of a beacon synchronized with beacon transmission times of each class B gateway of said network.
    According to a fourth aspect of the invention, the invention relates to a method of synchronizing a gateway implemented in a long-range wireless network and allowing a low power consumption, intended to allow a gateway to operate according to a communication mode, called class B, in which communication periods are defined from periodic beacon transmissions by each gateway of said network supporting said mode, said class B gateways, the beacon transmissions being synchronized between each gateway class B, each communication period being divided into a predefined number of sub-periods, a terminal of the network operating in said mode being able to communicate bidirectionally with a server via a class B gateway only during a sub-period allocated to it. The method is implemented by a system and comprises the method according to the first aspect implemented by a first gateway, the method according to the second aspect implemented by a second gateway (12A), the second gateway being class B and being equipped with synchronization means and the method according to the third aspect implemented by a server.
    According to one embodiment, the frame comprising the request for synchronization assistance comprises a unique identifier enabling the server to determine which gateway has made the request for synchronization assistance.
    According to one embodiment, the sub-period used to transmit a synchronization frame is determined by the first gateway and the information representative of a response to the synchronization assistance request includes information representative of said sub-period.
    According to one embodiment, the sub-period used to transmit a synchronization frame is determined by the server and the frame comprising the request for synchronization assistance comprises information representative of said sub-period.
    According to one embodiment, said method is implemented for a predetermined duration.
    According to one embodiment, a plurality of synchronization frames are transmitted with a predetermined periodicity.
    According to one embodiment, when the sub-period used to transmit the synchronization frame coincides with a sub-period allocated to the second gateway for other communications, the server designates, temporarily or permanently, another class B gateway. network, equipped with synchronization means, for transmitting at least one synchronization frame to the first gateway.
    According to one embodiment, prior to the transmission of the frame comprising the request for synchronization assistance, the first gateway transmits to the server a request for assistance with the preliminary synchronization using a direct communication link with the server, initiating a server implementation of a preprocessing procedure for the server to determine whether to allow the first gateway to transmit the frame including the synchronization help request.
    According to one embodiment, prior to the transmission of the frame comprising the synchronization assistance request, the server sends a request to the first gateway requesting the first gateway to transmit a frame comprising a request for assistance to the synchronization. the synchronization.
    According to one embodiment, the information representative of a response to the request for synchronization assistance includes information enabling a plurality of gateways, including the first gateway, to determine at least one next transmission instant of a tag by each class B gateway of said network and transmit a tag at each next determined transmission time.
    According to one embodiment, the network is a LoRa network.
    According to a fifth aspect of the invention, the invention relates to a gateway type device comprising means for implementing the method according to the first aspect.
    According to a sixth aspect, the invention relates to a gateway type device comprising means for implementing the method according to the third aspect.
    According to a seventh aspect of the invention, the invention relates to a server-type device comprising means for implementing the method according to the second aspect.
    According to an eighth aspect, the invention relates to a system comprising at least one device according to the fifth aspect, at least one device according to the sixth aspect and a device according to the seventh aspect.
    The characteristics of the invention mentioned above, as well as others, will emerge more clearly on reading the following description of an exemplary embodiment, said description being given in relation to the attached drawings, among which: Fig. 1 schematically illustrates a LoRa network in which the invention is implemented; FIG. 2A schematically illustrates a processing module included in a server; FIG. 2B schematically illustrates a processing module included in a gateway not including synchronization means; FIG. 2C schematically illustrates a processing module included in a gateway comprising synchronization means; FIG. 3A schematically illustrates a first exemplary method according to the invention for synchronizing a gateway having no synchronization means; and, - 3B schematically illustrates a second exemplary method according to the invention for synchronizing a gateway having no synchronization means. The invention is described later in a LoRa network context. However, the invention applies in other contexts for all types of long-range wireless networks and for low power consumption where the base stations synchronously transmit a beacon.
    We also note that we describe a LoRa network with a server. The term server is here a generic term that can represent a server or a plurality of servers connected to each other comprising an application server adapted to manage applications implemented by terminals of a LoRa network.
    Fig. 1 schematically illustrates a LoRa network in which the invention is implemented.
    In the example of FIG. 1, the LoRa 1 network comprises a server 10, three macro-gateways 12A, 12B and 12C, a femto-gateway 11 and a terminal 13. The macro-gateway 12A (respectively the macro-gateway 12B, the macro-gateway 12C and the femto-gateway 11) communicates with the server 10 via a communication link 15A (respectively 15B, 15C and 15D). This link is usually a link on an IP network ("Internet Protocol" in English terminology) whose physical support does not matter (wired and / or wireless) and that is named afterwards direct link to the server 10, even if in reality several network nodes can separate a gateway of said server 10. The macro-gateway 12A (respectively the macro-gateway 12B, the macro-gateway 12C and the femto-gateway 11) communicates with the terminal 13 via a 14A wireless communication link (respectively 14B, 14C and 14D) using LoRa technology. The femto-gateway 11 communicates with the macro-gateway 12A via a wireless communication link 16. The femto-gateway 11 can communicate in the same way with the macro-gateways 12B, 12C via wireless communication links not shown. Each communication between gateways is done using the same radio interface as that supported by the LoRaWAN protocol to communicate with terminals. Thus a gateway is temporarily passed for a terminal.
    The server 10 comprises a processing module 100. The femto-gateway 11 comprises a processing module 110. Each macro-gateway 12A, 12B and 12C comprises a processing module 120. Only the processing module 120 of the gateway 12A is represented .
    It should be noted that the communications between the terminals and the gateways and the communications between the gateways of a LoRa network use frames compatible with the LoRaWAN protocol, these frames comprise only one field that can contain an address (with the exception of the tags which do not include any address). LoRaWAN-compatible frames are transmitted in point-to-all mode ("broadcast" in English terminology) in the uplink direction, i.e. to the serverlO; and in point-to-point mode ("unicast" in English terminology) or in point-to-multi-point mode ("multicast" in English terminology) in the downward direction, ie from the server 10. In the following, we speak of frames transmitted in multicast mode, the direction of direction raising the ambiguity obviously for the skilled person. The communications between the server 10 and the gateways (macro-gateways 12A, 12B and 12C and femto-gateway 11) use, for example, a protocol of the HTTP type based on requests.
    When the terminal 13 wishes to transmit a frame, said rising frame, containing application data and / or control information, said rising frame is transmitted in multicast mode. Each gateway within range of the terminal 13, here the macro-gateways 12A, 12C and 12B and the femto-gateway 11 receives the upstream frame and inserts it into an HTTP request, called a rising HTTP request, which is transmitted to the server 10. The server 10 therefore receives a rising HTTP request from each gateway that has received the upstream frame. The server 10 then sends the application data to an application server associated with the terminal 13 (not shown) and manages the control information.
    When the server 10 has to transmit application data from the application server and / or wishes to transmit control information to the terminal 13, it creates information necessary for the creation of a downlink to be transmitted to the terminal 13 and inserts it in an HTTP request, said downlink HTTP request, and transmits the request to a single gateway that it designates among the gateways that received the upstream frame (here one of the macro-gateways 12A, 12B or 12C or femto-gateway 11). The application data and / or the control information for terminal 13 is extracted from the information contained in the downstream HTTP request and is then transmitted in a multicast frame by the designated gateway to terminal 13. It is noted that the server 10 knows how to uniquely identify all the LoRa 1 network gateways.
    In the example of FIG. 1, it is assumed that the femto-gateway has no means of synchronization, but that each macro-gateway has such means (such as a GPS module). However, the gateway having no synchronization means in the LoRa 1 network could equally well have been one of the macro-gateways 12A, 12B and 12C.
    There are two modes of communication in a LoRa network: a first communication mode, called class A, and a second mode of communication, called class B.
    In the class A communication mode, a terminal operating in the class A communication mode, called class A terminal, having sent an upstream frame to a server defines two reception windows following the transmission of the rising frame. Each receive window represents a period during which the class A terminal listens for a downlink containing data from the server. The two reception windows therefore represent the only two opportunities for the server to communicate with the terminal following the transmission of an upstream frame. A bidirectional transmission between the class A terminal and the server can only be done at the initiative of the class A terminal. Indeed, the class A terminal only listens to receive a downlink during both reception windows to save energy.
    In the class B communication mode, a procedure is set up so that a terminal operating in the class B operating mode, said class B terminal, only wakes up at specific times negotiated with the server. To do this, communication periods are defined. Each communication period is defined from periodic beacon transmissions by the LoRa network gateways, a communication period being located between two beacons. Each communication period is divided into a number of sub-periods ("ping slots" in English terminology) predefined by the LoRaWAN protocol. A class B terminal of a LoRa network can only bidirectionally communicate with the server through a gateway supporting class B communication mode, called class B gateway, for a certain number of years. -periods that have been allocated to him. In practice, in a LoRa network, tags are periodically issued with a period of "128 s" and sub-periods of "30 ms" are spread over a period of communication of "122,880 s" following each tag. Each sub-period of a communication period is at a fixed position relative to each of the two beacons enclosing said communication period. There is therefore a predefined gap by the LoRaWAN protocol between the preceding beacon (respectively following) a communication period and each sub-period of said communication period. It is therefore important that tag transmissions by the gateways of a LoRa network are synchronized with each other with sufficient precision to support the class B communication mode without error.
    Note that a terminal connecting to a LoRa network operates by default in class A communication mode and it is at its request that it can switch to a class B communication mode.
    The macro-gateways 12A, 12B and 12C are class B gateways. The femto-gateway 11 is, initially, a class A gateway. The synchronization method according to the invention will enable the femto-gateway 11 to become, at least temporarily, a class B gateway.
    Fig. 2A schematically illustrates an example of hardware architecture of the processing module 100 included in the server 10.
    According to the example of hardware architecture shown in FIG. 2A, the processing module 100 then comprises, connected by a communication bus 1000: a processor or CPU ("Central Processing Unit" in English) 1001; Random Access Memory (RAM) 1002; a ROM (Read Only Memory) 1003; a storage unit such as a hard disk or a storage medium reader, such as a Secure Digital (SD) card reader 1004; at least one communication interface 1005 enabling the processing module 100 to communicate with other modules or devices. For example, the communication interface 1005 enables the processing module 100 to communicate with other modules of the server 10 or with other devices such as the macro-gateways 12A, 12B, 12C and the femto-gateway 11.
    The processor 1001 is capable of executing instructions loaded into the RAM 1002 from the ROM 1003, an external memory (not shown), a storage medium (such as an SD card), or a communication network. When the server 10 is turned on, the processor 1001 is able to read RAM 1002 instructions and execute them. In one embodiment, these instructions form a computer program causing the processor 1001 to completely or partially implement the methods described below in relation with FIGS. 3A and 3B.
    Fig. 2B schematically illustrates an example of hardware architecture of the processing module 110 included in the femto-gateway 11.
    According to the example of hardware architecture shown in FIG. 2B, the processing module 110 then comprises, connected by a communication bus 1100: a processor or CPU ("Central Processing Unit" in English) 1101; Random Access Memory (RAM) 1102; a ROM (Read Only Memory) 1103; a storage unit such as a hard disk or a storage medium reader, such as a Secure Digital (SD) card reader 1104; at least one communication interface 1105 enabling the processing module 110 to communicate with other modules or devices. For example, the communication interface 1105 allows the processing module 110 to communicate with the server 10, with the macro-gateways 12A, 12B and 12C or with the terminal 13.
    The processor 1101 is capable of executing instructions loaded into the RAM 1102 from the ROM 1103, an external memory (not shown), a storage medium (such as an SD card), or a communication network. When the femto-gateway 11 is powered up, the processor 1101 is able to read instructions from RAM 1102 and execute them. In one embodiment, these instructions form a computer program causing the processor 1101 to completely or partially implement the methods described hereinafter with reference to FIGS. 3A and 3B.
    Fig. 2C schematically illustrates an example of hardware architecture of the processing module 120 included in the macro-gateway 12A.
    According to the example of hardware architecture shown in FIG. 2C, the processing module 120 then comprises, connected by a communication bus 1200: a processor or CPU ("Central Processing Unit" in English) 1201; Random Access Memory (RAM) 1202; a ROM (Read Only Memory) 1203; a storage unit such as a hard disk or a storage medium reader, such as a 1204 Secure Digital (SD) card reader; at least one communication interface 1205 enabling the processing module 120 to communicate with other modules or devices. For example, the communication interface 1205 allows the processing module 120 to communicate with the server 10, with the femto-gateway 11 or with the terminal 13.
    The processor 1201 is capable of executing instructions loaded into the RAM 1202 from the ROM 1203, an external memory (not shown), a storage medium (such as an SD card), or a communication network. When the macropasserelle 12A is turned on, the processor 1201 is able to read instructions from RAM 1202 and execute them. In one embodiment, these instructions form a computer program causing the processor 1201 to completely or partially implement the methods described below in relation with FIGS. 3A and 3B.
    The methods described in connection with FIGS. 3A and 3B can be implemented in software form by executing a set of instructions by a programmable machine, for example a DSP ("Digital Signal Processor" in English) or a microcontroller, or be implemented in hardware form by a machine or a dedicated component, for example an FPGA ("Field Programmable Gate Array" in English) or an ASIC ("Application-Specific Integrated Circuit" in English).
    Fig. 3A schematically illustrates a first exemplary method according to the invention for synchronizing a gateway having no synchronization means.
    In the example of FIG. 1, this method is applied to synchronize the femto-gateway 11 so as to allow the femto-gateway 11 to become a class B gateway. In this method, the femto-gateway 11, having no means of synchronization, is assisted by another gateway, here one of the gateways 12A, 12B and 12C, having synchronization means, to perform its synchronization.
    In a step 32, the processing module 110 of the femto-gateway 11 sends an uplink to the server 10 comprising a request for synchronization assistance, called synchronization help request frame, via gateways located near the femto-gateway 11. To do this, the femto-gateway 11 is temporarily pass for a terminal. The synchronization help request frame is broadcast in multicast mode.
    During steps 33, 34 and 35, a copy of the synchronization assistance request frame is received by each gateway within range of the femto-gateway 11, here the macro-gateways 12A, 12B and 12C. During steps 33, 34 and 35, the content of the synchronization assistance request frame is inserted by each gateway that has received said frame in a rising HTTP request destined for the server 10. Each gateway having received the request frame of synchronization aid then transmits a rising HTTP request, containing the request for synchronization help, to the server 10.
    A request for synchronization assistance issued in step 32 includes a unique identifier AddID allowing the server 10 to determine which gateway has made the request for synchronization assistance. The unique identifier AddID is similar to an address. It is therefore considered that the unique identifier AddID represents an address, called the synchronization address. In the example of FIG. 1, the request for synchronization assistance includes a unique identifier AddID of the femto-gateway 11. The server 10 is supposed to be able to uniquely associate a unique identifier AddID, which it would receive through the help frame at synchronization, at the gateway of the LoRa 1 network which would insert in said synchronization aid frame said unique identifier AddID. In one embodiment, each gateway of the LoRa 1 network obtains a unique identifier AddID when it is installed in the LoRa 1 network.
    In one embodiment, the request for synchronization assistance comprises information representative of a PS sub-period ("Ping Slot") of a communication period during which the femto-gateway He wants another gateway to send him a synchronization frame. Note that the PS sub-period used to transmit a synchronization frame is located at a fixed position in a communication period. Preferably, the sub-period PS used to transmit a synchronization frame is located near the beacon following the communication period comprising said sub-period PS. For example, said sub-period PS is the last sub-period of the communication period located just before the transmission of the beacon following the communication period comprising said sub-period PS. By taking a sub-period PS preferably located shortly before the issuance of the beacon, it limits risks of clock drift of the femto-gateway 11 during the communication period following said beacon. We describe the synchronization frames later.
    In one embodiment, following the transmission of the synchronization assistance request frame, the femto-gateway 11 starts a timer. If no response to the synchronization help request frame is received after a predefined timeout period, femto-gateway 11 may decide to renew its request for synchronization assistance by issuing a new request frame of helps with synchronization. On the other hand, for example, if, after a number Nr (Nr being an integer greater than "0"), synchronization assistance request renewals, no response to said request is received, the femto-gateway 11 terminates his requests for help with synchronization. The femto-gateway is then unable to operate in class B communication mode.
    In a step 36, the server 10 receives a plurality of upstream HTTP requests each containing the same request for synchronization assistance formulated by the femto-gateway 11 and relayed by the macro-gateways 12A, 12B and 12C.
    In a step 37, the processing module 100 verifies that the request for synchronization assistance emanates from a gateway of the LoRa 1 network using the unique identifier AddID contained in said request. Step 37 is optional since it is implemented only when there is a risk for a synchronization assistance request frame from a gateway of another LoRa network that the LoRa network. 1 is received by a gateway of the LoRa 1 network.
    In a step 38, the processing module 100 verifies a feasibility of the synchronization aid. To do this, the processing module 100 checks whether at least one gateway, among the gateways of the LoRa 1 network relaying the request for synchronization assistance, is capable of helping the femto-gateway 11 to synchronize. It is necessary for a first gateway to help synchronize a second gateway that the first gateway is equipped with synchronization means such as a GPS module. It is assumed here that each gateway equipped with synchronization means has transmitted this information to the server 10. The processing module 100 is therefore able to determine which gateway, among the macropasserelles 12A, 12B and 12C, is equipped with synchronization means. Furthermore, the processing module 100 knows which gateways of the LoRa 1 network are within range of the femto-gateway 11. Indeed, the gateways that are in range are the gateways having relayed the request for assistance with the synchronization, ie the macro-gateways 12A, 12B and 12C in the case of the example of FIG. 1. If at least one of the gateways relaying the request for synchronization assistance is equipped with synchronization means, the processing module 100 considers that the synchronization help is possible. Otherwise, help with synchronization is impossible.
    In a step 39, the processing module 100 decides to accept or reject and sends a message to the femto-gateway 11 including information representative of this decision.
    When help with synchronization is not possible, the decision made by the processing module is a refusal. In this case, the message sent to the femto-gateway 11 is a refusal message. The refusal message is for example a downlink HTTP request including information representative of the refusal. This message is sent during a step 40 on the link 15D.
    In a step 41, the processing module 110 of the femto-gateway 11 receives the rejection message and ends its synchronization attempt.
    When the synchronization help is possible, the processing module 100 allows the synchronization help. In this case, during a step 42, the processing module 100 designates one of the macro-gateways 12A, 12B or 12C to relay information representative of a response to the request for assistance with synchronization. For example, each uplink HTTP request contains information representing a reception quality of the synchronization assistance request frame by the gateway having transmitted said uplink HTTP request. For example, the processing module 100 designates the gateway that has received the synchronization request request frame with the best quality. In the example of FIG. 1, the macropasser 12A is designated by the processing module 100. In one embodiment, the gateway designated to respond to the request for synchronization assistance is also the gateway that provides the synchronization help.
    In a step 43, the processing module 100 transmits a downlink HTTP request comprising information representative of a response to the request for synchronization assistance to the macro-gateway 12A. The information representative of a response includes the unique identifier AddID of the gateway requesting synchronization assistance, here the femto-gateway 11. As we describe below, the information representative of a response transmitted in the downlink HTTP request to the macro-gateway 12A, allow to set up a transmission of at least one synchronization frame by the macro-gateway 12A to femto-gateway 11 in the sub-period PS of at least one communication period, thus allowing femto-gateway 11 to determine beacon transmission times synchronized with the tag emitting times of each class B gateway LoRa network 1.
    In one embodiment, the information representative of a response further comprises information representative of the PS sub-period to be used to transmit a synchronization frame if this PS sub-period is not the same as that proposed by the processing module 110 of the femto-gateway 11 in the synchronization assistance request frame.
    In one embodiment, the information representative of a response further comprises a synchronization address, represented by an identifier, called global identifier, PingAddID which is an address used in synchronization assistance frames as destination address, the global identifier PingAddID may be different from the unique identifier AddID used by the femto-gateway 11 during its request for synchronization assistance in step 32. This may be particularly useful for example if a method of synchronization aid is already set up by the server 10 for a second femto-gateway (not shown in Fig. 3A) through one of the macro-gateways in the vicinity of the femto-gateway 11. The knowledge of the global identifier PingAddID used in the synchronization frames to the second femto-gateway allows femto-gateway 11 to be able to e to operate without new synchronization frames being specifically generated for femto-gateway 11 with its unique identifier AddID. In this way, a plurality of gateways (here the femto-gateway 11 and at least one other femto-gateway) can synchronize with the help of the same gateway (here the macro-gateway 12A) using the same frame of synchronization. The global identifier PingAddID is therefore information enabling a plurality of gateways to determine at least one next moment of transmission of a beacon by each class B gateway of said LoRa 1 network and to transmit a beacon at each next instant of time. determined issue. In one embodiment, when the second femto-gateway already receives synchronization frames whose destination address has its unique identifier AddID equal to an AddID_FT2 value, it may be wise to use these same frames to help synchronize the femto gateway 11. This is done by setting the global identifier PingAddID to the value AddID_FT2 of the unique identifier AddID of the second femto-gateway in the response to the synchronization help request of the femto-gateway 11. From this way we avoid reserving global identifier values PingAddID in addition to the unique identifier values AddID.
    In a step 44, the downlink HTTP request containing the information representative of a response to the request for synchronization assistance is received by the macro-gateway 12A. Said response enables the macro-gateway 12A to determine in which PS sub-period of at least one communication period the macro-gateway 12A must transmit a synchronization frame and to which recipient: either at the synchronization address represented by the unique identifier AddID if the global identifier PingAddID is not present in the information representative of a response to the request for synchronization assistance, or to the synchronization address represented by the global identifier PingAddID if the identifier global PingAddID is present in the information representative of a response to the synchronization help request. The macro-gateway 12A extracts said information and inserts it into a downlink destined for the gateway corresponding to the unique identifier AddID, i.e. the femto-gateway 11. Said downlink frame is transmitted in multicast mode.
    In a step 45, the processing module 110 of the femto-gateway 11 receives the downstream frame comprising the information representative of a response to the synchronization assistance request frame from the macro-gateway 12A. The reception of the downward frame allows the femto-gateway 11, through its processing module 110, to determine at least one communication period during which the femto-gateway 11 must receive a synchronization frame from of the macro-gateway 12A. For example, the reception of the downstream frame indicates to the sub-gateway 11, that after reception of a number Nb of tags, the femto-gateway 11 will receive at least one synchronization frame, from the macro-gateway 12A in the transmission period following receipt of the NB number of tags. The femto-gateway 11 then uses each received synchronization frame to synchronize. Each synchronization frame is received in a sub-period PS of a communication period corresponding to either the sub-period PS indicated in the synchronization assistance request frame or the sub-period PS indicated in the frame. descendant comprising the information representative of a response to the request for assistance with synchronization. In one embodiment, the number of NB beacons is predefined and known from each gateway of the LoRa network 1. In one embodiment, the number of beacons NB = 1, that is to say that the next communication period the next received tag comprises a PS sub-period in which a synchronization frame is transmitted. In one embodiment, the number of beacons NB = 5.
    In one embodiment, the number of NB tags is part of the information representative of a response to the request for synchronization assistance. This number of NB tags is therefore received in the downlink comprising the information representative of a response to the request for assistance with synchronization.
    In a step 46, the processing module 110 obtains the information representative of the sub-period PS used by the macro-gateway 12A to transmit the synchronization frame. This information is either known to the processing module 110 since it was he who defined it during the step 32, or extracted from the downward frame comprising the information representative of a response to the request frame of assistance to the synchronization received during step 45.
    In the embodiment where a global identifier PingAddID is included in the information representative of a response to the synchronization assistance request frame, the processing module 110 uses the synchronization frames whose destination address includes the synchronization frame. global identifier PingAddID and not the unique identifier AddID to synchronize.
    In a step 47, the processing module 110 starts a counter, and counts the number of beacons received following the reception of the downstream frame comprising the information representative of a response to the request for assistance with the synchronization.
    Simultaneously with step 47, following the sending of the downlink comprising the information representative of a response to the request for assistance with synchronization, the processing module 120 of the macro-gateway 12A starts, when a step 48, a counter, and counts the number of beacons transmitted following the transmission of said downlink. When the number of beacons transmitted reaches the number of beacons Nb, the processing module 120 proceeds to a step 49 during which it transmits a synchronization frame in the sub-period PS of the next communication period. If, prior to receiving the last downlink HTTP request containing information representative of a response to the synchronization help request, the processing module 120 of the macro-gateway 12A has received another downlink HTTP request containing information representative of a response to a request for synchronization assistance, the processing module 120 takes into account the information representative of a response contained in the last downlink HTTP request received if this information is different between the two downstream HTTP requests .
    When the number of beacons received by the femto-gateway 11 reaches the number of beacons NB, the processing module 110 of the femto-gateway 11 proceeds to a step 50. The femto-gateway 11 then expects to receive a frame of synchronization in the PS sub-period of the next communication period. In step 50, the processing module 110 receives the synchronization frame. The processing module 110 then knows that this synchronization frame was received during a sub-period PS. Because of its knowledge of the LoRaWAN protocol, the processing module 110 knows the predefined distance between the sub-period PS and the next beacon sent by each class B gateway of the LoRa 1 network (the macro-gateways 12A, 12B and 12C). . From the instant of reception of the synchronization frame and the predefined distance, the processing module 110 determines at least the next instant of transmission of a beacon by each class B gateway of the LoRa 1 network (here the macro-gateways 12A, 12B and 12C). The processing module 110 knowing the beacon period in the LoRa 1 network can then synchronize its own beacon transmissions with the beacon transmissions of the other class B gateways of the LoRa 1 network (here the macropasserelles 12A, 12B and 12C). If the femto-gateway comprises a reliable clock, then a single reception of a synchronization frame is sufficient to synchronize the beacon transmissions of the femto-gateway 11. If the clock of the femto-gateway is not sufficiently reliable then the beacon transmissions must be synchronized regularly to compensate drifts of the clock of the femto-gateway 11.
    Following the reception of the synchronization frame during step 50, in a step 51, the processing module 110 transmits a beacon at each instant of emission determined during step 50. In other words, the processing module 110 transmits at least one synchronized beacon with the transmitted beacons (not shown in Fig. 3A) by the other class B gateways of the LoRa 1 network.
    In an embodiment, a plurality of synchronization frames are transmitted with a predetermined periodicity P. Femto-gateway 11 can thus resynchronize each time a synchronization frame is received (repetition of steps 49, 50 and 51). The periodicity P is for example a known default periodicity of each gateway of the LoRa network 1. In one embodiment, the periodicity P is defined by the femto-gateway 11 and information representative of this periodicity is transmitted towards the server 10 in the synchronization help request frames. The server 10 then transmits the information representative of the periodicity to the gateway of the network 1 designated to help the femto-gateway 11 to synchronize. In one embodiment, the periodicity P is defined by the server 10 which transmits information representative of the periodicity P to the gateway of the network 1 designated to help the femto-gateway 11 to synchronize and femto-gateway 11.
    In one embodiment, the synchronization frame contains the unique identifier AddID of the gateway for which it is intended, here femto-gateway 11, if the global identifier Ping AddID is not present in the information representative of a response to the request for help with synchronization. In one embodiment, the synchronization frame contains the global identifier PingAddID as the destination address if said global identifier PingAddID is present in the information representative of a response to the request for assistance with the synchronization.
    In one embodiment, the synchronization frame further contains information representative of an instant at which the synchronization frame was transmitted by the macro-gateway 12A. The instant at which the synchronization frame has been sent allows the femto-gateway 11 to calculate a propagation time of the frame between the macro-gateway 12A and the femto-gateway 11, and to take this propagation time into account when synchronization. In this way, the synchronization is made reliable.
    It is known that in a LoRa network, a sub-period of a communication period allocated to a conventional class B terminal changes deterministically between two tag transmissions. In one embodiment, when the sub-period PS used to transmit the synchronization frame coincides with a sub-period allocated for other communications through the gateway to transmit the synchronization frame, here the macro-gateway 12A , the processing module 100 of the server 10 designates, temporarily or permanently, another gateway of the LoRa 1 network within range of the femto-gateway 11 to transmit the synchronization frames.
    In one embodiment, the synchronization aid is granted, i.e. the synchronization method described in connection with FIG. 3A is implemented for a duration D. During the duration D, the femto-gateway 11 transmits beacons and synchronizes its beacon transmissions with each synchronization frame it receives. In one embodiment, during the duration D, the macro-gateway 12A periodically transmits a synchronization frame with the periodicity P. In one embodiment, the duration D is a default duration known by each gateway of the LoRa 1 network. For example, the duration D can be equal to "24" hours or infinite. In one embodiment, the duration D is set by the server 10 and received by the processing module 110 of the femto-gateway 11 in the response to the request for synchronization assistance during step 45. to do, the server 10 can analyze a traffic due to the class B terminals in a geographical area including the femto-gateway 11 and identify regular periods of affluence (ie periods of overload of the LoRa 1 network) during which the macro-gateways 12A , 12B and 12C are overloaded. The femto-gateway 11 can then be used to relieve the macro-gateways 12A, 12B and 12C. The duration D can then be defined according to these periods of affluence. In one embodiment, at the end of the duration D, the femto-gateway 11 renews its request for synchronization assistance if necessary, by restarting the method described in relation with FIG. A. In another alternative embodiment to the previous one, the server 10 is the initiator of the renewal of the synchronization aid. In this case, the processing module 100 of the server 10 repeats the method described in relation to FIG. 3A from step 43 and steps 44-51 are implemented.
    In one embodiment, once the synchronization aid has started, the processing module 100 of the server 10 observes terminal communications using the femto-gateway 11. In the event of abnormal operation of these communications, the module Processing 100 of the server 10 terminates the synchronization aid without waiting for the end of the duration D. An abnormal operation is characterized for example by a number of repetitions of frames passing through the femto-gateway 11 greater than a predefined threshold. The processing module 100 of the server 10 informs the femto-gateway 11 of the end of the synchronization aid, for example, by sending it a downlink HTTP request containing information indicating the end of the synchronization help or by asking another gateway of the LoRa 1 network to transmit femto-gateway 11 a frame containing information indicating the end of the synchronization help.
    In one embodiment, the synchronization assistance request frames, the synchronization assistance request response frames, and the synchronization frames are dedicated frames for synchronization assistance that complement Existing frames defined in the LoRaWAN protocol.
    In one embodiment, the synchronization help request frames, the synchronization help request response frames, and the synchronization frames are existing frames in the LoRaWAN protocol into which new fields are inserted. for carrying information and / or data exchanged during the implementation of the synchronization method described in connection with FIG. 3A.
    In one embodiment, the synchronization assistance request frames, the synchronization assistance request response frames, and the synchronization frames are existing frames in the LoRaWAN protocol in which fields not used by the LoRaWAN protocol are used to convey information and / or data exchanged during the implementation of the synchronization method described in relation to FIG. 3 A.
    We have seen above that during steps 40 and 41, the refusal message definitively ended the synchronization assistance process. In an alternative embodiment, the refusal message invites the femto-gateway 11 to later renew its transmission of a request frame for synchronization assistance. In this case, after a waiting period, for example predefined, following the reception of the refias message, femto-gateway 11 again implements step 32 by transmitting a new help request frame to the synchronization.
    In one embodiment, prior to the implementation of step 32, the processing module 110 of the femto-gateway 11 transmits a first synchronization assistance request, called a request for assistance with the preliminary synchronization, via the link 15D without passing through the macro-gateways 12A, 12B and 12C. This request for assistance with the preliminary synchronization is transmitted for example in the form of a rising HTTP request containing the same information as that transmitted during the steps 33, 34 and 35. When it receives this rising HTTP request, the processing module 100 of the server 10 implements a preprocessing procedure allowing the server 10 to determine whether the femto-gateway 11 may be authorized to transmit a synchronization assistance request frame. During this preprocessing procedure, the processing module 100 analyzes, for example, a load of the LoRa 1 network in a geographical zone encompassing the femto-gateway 11. If the load of the LoRa 1 network due to the class B terminals is greater than a predefined load level, the processing module 100 decides to allow the femto-gateway 11 to start the implementation of the synchronization method described in relation to FIG. A. To do this, the processing module 100 transmits a downlink HTTP request to the femto-gateway 11, indicating to it that it is authorized to transmit a request frame for synchronization assistance. Following reception of this downstream HTTP request, the processing module 110 of the femto-gateway 11 implements step 32. If the load of the LoRa 1 network due to the class B terminals is less than or equal to the load level predefined, the processing module 100 sends a refusal message to the femto-gateway 11. As described above, this refusal message can be a definitive refusal or an invitation to renew the request for synchronization assistance at a later date. . The later date can be predetermined and known from each gateway of the LoRa 1 network, defined by the femto-gateway 11 or defined by the processing module 100 of the server 10 and transmitted in the refusal message. In one embodiment, rather than allowing the femto-gateway 11 to renew a request for synchronization assistance at a later date, the processing module 100 decides, when the load of the LoRa network is less than or equal to the load level. predefined, to take into consideration the request of the femto-gateway 11. If, after a given period, the processing module 100 finds that the load of the LoRa 1 network in the geographical area encompassing the femto-gateway 11 exceeds the level of load predefined, it allows femto-gateway 11 to implement step 32.
    In one embodiment, the femto-gateway 11 uses the transmission of a request for assistance with the preliminary synchronization to obtain a renewal of the duration D if it is not infinite. An advantage of this embodiment is that the renewal of the duration D is granted by the server 10 only if the preprocessing procedure allows it. In this way, the implementation of the synchronization assistance procedure is renewed only if the load of the LoRa 1 network justifies it.
    Until then, the launch of the synchronization assistance procedure has always been initiated by the femto-gateway 11. In one embodiment, the server 10 decides for itself, without prior receipt of a request. request for synchronization assistance, to help the femto-gateway 11 to synchronize so that the femto-gateway 11 can operate in class B communication mode. This embodiment is, for example, implemented when, after analyzing the load of the LoRa 1 network due to the class B terminals, the server 10 finds that the LoRa 1 network is overloaded in a geographic area encompassing the femto-gateway 11. To do this the server 10, through its processing module 100 sends a request for implementation of step 32 to femto-gateway 11. This request is for example transmitted in the form of a downlink HTTP request, comprising information representative of a request for a spear synchronization method, transmitted to the femto-gateway 11 using the link 15D. Following reception of this downward HTTP request, the processing module 110 of the femto-gateway 11 implements step 32.
    In one embodiment, the femto-gateway 11 does not permanently have a unique identifier AddID. The unique identifier is assigned to the gateway 11 by the processing module 100 of the server 10, ie during the transmission of the launch request of the synchronization assistance method (the unique identifier AddID is then included in the request Downstream HTTP comprising the information representative of a request for launching the method of assisting synchronization), or during the transmission of the downstream HTTP request indicating to femto-gateway 11 that it is authorized to implement the method of assisting synchronization (ie following receipt by the server 10 of a request for assistance with the preliminary synchronization).
    In one embodiment, it is not the femto-gateway 11 that defines the sub-period PS. In this case, the synchronization assistance request frame sent by the sub-gateway 11 does not include this information. It is then the processing module 100 of the server 10 which defines the sub-period PS. The processing module 100 then transmits information representative of the sub-period PS in the downlink HTTP request comprising information representative of a response to the request for synchronization assistance transmitted to the macro-gateway 12A, said information being intended at the femto-bridge 11.
    In one embodiment, before issuing the synchronization help request frame in step 32, the femto-gateway 11 checks whether other gateways are within range to receive said help request frame. synchronization and to transmit synchronization frames. Such a verification can be based on an analysis of the beacons received by the femto-gateway 11. A beacon reception means that at least one gateway is within range of the femto-gateway 11. If no gateway is within range, Femto-gateway 11 does not implement the method described in relation to FIG. 3A.
    Fig. 3B schematically illustrates a second exemplary method according to the invention for synchronizing a gateway having no synchronization means.
    The process described in connection with FIG. 3B is very similar to the method described in connection with FIG. 3A and can replace the method described in connection with FIG. 3A. Steps 32 to 43, 45 to 47, 50 and 51 remain identical. Step 44 is replaced by a step 440 implemented by the macro-gateway 12A. Step 48, implemented by the macro-gateway 12A is replaced by a step 480 implemented by the server 10. The step 49 implemented by the macro-gateway 12A is replaced by a step 490 implementation by the server 10 and by a step 491 implemented by the macro-gateway 12A.
    In the method described in connection with FIG. 3B, the server 10 transmits a downlink HTTP request to the macro-gateway 12A for each synchronization frame. It is therefore the server 10 that fully controls the transmission of the synchronization frames. In this method, the macro-gateway 12A serves only to relay the downstream HTTP requests from the server 10 to a recipient of the LoRa 1 network without worrying about the content of said requests (conventional operation of a LoRa network gateway) . By default, all downstream HTTP requests contain all the information necessary for the macro-gateway 12A in order to form a frame to be transmitted at a given instant by the server 10.
    In step 440, the downstream HTTP request containing the information representative of a response to the synchronization assistance request is received by the macro-gateway 12A. The macro-gateway 12A extracts said information and inserts it into a downlink destined for the gateway corresponding to the unique identifier AddID, i.e. the femto-gateway 11, or intended for each gateway identified by the global identifier PingAddID. Said downlink is transmitted in multicast mode. Unlike step 44, during step 440, the macro-gateway 12A does not determine in which sub-period PS of at least one communication period said macro-gateway 12A must transmit a synchronization frame and to which recipient (AddID or PingAddID). In the method described in connection with FIG. 3B, the femto-gateway 11 receives the downlink containing the information representative of a response to the synchronization assistance request during the step 45 already explained.
    Following the sending of the downstream HTTP request comprising the information representative of a response to the request for assistance with the synchronization, the processing module 100 of the server 10 starts, during the step 480, a counter, and counts the number of beacons transmitted following the transmission of said downstream HTTP request. When the number of transmitted beacons reaches the number of NB beacons, the processing module 100 proceeds to step 490 during which, it transmits a downlink HTTP request containing information representative of the transmission of a synchronization frame during the PS sub-period of the next communication period. This downward HTTP request makes it possible to trigger in step 491 a sending by the macro-gateway 12A of a synchronization frame in the sub-period PS of the next communication period. The femto-gateway 11 implements step 50 following the reception of the synchronization frame. Step 490 is repeated during duration D.
    In the case where the sub-period PS coincides with a sub-period allocated to the macro-gateway 12A to communicate another frame, called the conventional frame, than the synchronization frame (a frame comprising application data or control information) , the server 10 can ask the macro-gateway 12A to favor the sending of the conventional frame. However, the femto-gateway 11 expecting, after receiving the synchronization request response frame, to receive a synchronization frame in the sub-period PS, it uses the conventional frame as a synchronization frame for synchronize tag shipments.
    In this embodiment, the server 10 finely controls the duration of the synchronization aid by controlling when it sends downward HTTP requests to trigger the transmission, by the macro-gateway 12A, synchronization frames.
    权利要求:
    Claims (20)
    [1" id="c-fr-0001]
    1) A method of synchronizing a gateway (11) of a network (1) wireless long-range and low energy consumption, for allowing said gateway to operate according to a communication mode, said class B, wherein communication periods are defined from periodic beacon transmissions by each gateway of said network (1) supporting said mode, said class B gateways, the beacon transmissions being synchronized between each class B gateway, each communication period being divided into a predefined number of sub-periods, a terminal (13) of the network (1) operating in said mode unable to bidirectionally communicate with a server (10) via a gateway of class B only during a sub-period allocated to it, the method being characterized in that it comprises, when implemented by a the first gateway (11): transmit (32) to said server (10), through at least one second gateway of said network (1), a frame comprising a request for synchronization assistance; receiving (45) a frame comprising information representative of a response to said request from a gateway of said network (1), designated gateway, equipped with synchronization means, the designated gateway having been designated by the server (10 ) among the at least one second gateway, the reception of said frame allowing the first gateway (11) to determine at least one communication period during which the first gateway (11) must receive a frame, called the synchronization frame, from the designated gateway; obtaining (46) information representative of a sub-period of each determined communication period used by the designated gateway for transmitting a synchronization frame, said sub-period having a predefined deviation with a tag immediately following the communication period; receiving (50) at least one synchronization frame; and, for each synchronization frame received: determining (50) from a reception instant of said synchronization frame and the predefined distance, at least one next instant of transmission of a tag by each class gateway B of said network (1); and transmitting (51) a beacon at each next determined transmission time.
    [0002]
    2) Method according to claim 1, characterized in that, before transmitting the frame comprising a request for assistance with synchronization, the first gateway checks whether at least one second gateway is in range to receive said frame and to transmit to the first gateway of the synchronization frames, no frame including a request for synchronization assistance being issued if no gateway is in range.
    [0003]
    3) Method according to claim 1 or 2, characterized in that, following the transmission of the frame comprising the synchronization assistance request, if no response to said frame is received after a predefined duration, the first Gateway renews its request for synchronization assistance by issuing a new request frame for synchronization help.
    [0004]
    4) A method of synchronizing a gateway (11) of a network (1) wireless long-range and low energy consumption, for allowing said gateway to operate in a communication mode, said class B, wherein communication periods are defined from periodic beacon transmissions by each gateway of said network (1) supporting said mode, said class B gateways, the beacon transmissions being synchronized between each class B gateway, each communication period being divided into a predefined number of sub-periods, a terminal (13) of the network (1) operating in said mode unable to bidirectionally communicate with a server (10) via a class gateway B that during a sub-period that has been allocated to it, the method being characterized in that it comprises, when implemented by the server (10): see (36) at least one request containing a request for synchronization assistance formulated by a first gateway and relayed by at least one second gateway; verify (38) a feasibility of a synchronization aid, synchronization assistance being possible when at least one of the at least one gateway is equipped with synchronization means; when the synchronization help is possible, designate (42) a second gateway, designated gateway, equipped with synchronization means, to relay to the first gateway information representative of a response to the request for synchronization assistance , said information making it possible to implement a transmission of at least one frame, called the synchronization frame, by the designated gateway, to the first gateway, in a predetermined sub-period of at least one communication period, each transmission of a synchronization frame enabling the first gateway to determine at least one transmission instant of a synchronized beacon with beacon transmission times of each class B gateway of said network; and, transmitting (43) a request including said information to the designated gateway.
    [0005]
    5) A method of synchronizing a gateway (11) of a network (1) wireless long-range and low energy consumption, for allowing said gateway to operate in a communication mode, said class B, wherein communication periods are defined from periodic beacon transmissions by each gateway of said network (1) supporting said mode, said class B gateways, the beacon transmissions being synchronized between each class B gateway, each communication period being divided into a predefined number of sub-periods, a terminal (13) of the network (1) operating in said mode unable to bidirectionally communicate with a server (10) via a class gateway Only during a subperiod which has been allocated to it, the method being characterized in that it comprises, when it is implemented by a second gate e said network, the second gateway being class B and being equipped with synchronization means: receiving (44) a request from the server comprising information representative of a response to a request for synchronization assistance formulated by a first gateway, said request having been relayed by the second gateway to said server; transmitting (44) a frame comprising said response to the request for synchronization assistance to the first gateway, said response enabling the first gateway to determine in which sub-period of at least one communication period the first gateway is to receive a synchronization frame; and, transmitting (49) at least one synchronization frame to the first gateway in said sub-period, receiving a synchronization frame in said sub-period allowing the first gateway to determine at least one transmission time of a beacon synchronized with beacon transmission times of each class B gateway of said network.
    [0006]
    6) Method for synchronizing a gateway implemented in a long-range wireless network (1) and allowing a low power consumption, intended to allow a gateway to operate according to a mode of communication, said class B , wherein communication periods are defined from periodic beacon transmissions by each gateway of said network (1) supporting said mode, said class B gateways, the beacon transmissions being synchronized between each class B gateway, each period communication device being divided into a predefined number of sub-periods, a terminal (13) of the network (1) operating in said mode unable to bidirectionally communicate with a server (10) via a class B gateway that during a sub-period allocated to it, the method being implemented by a system and comprising the method according to claim 1 set implemented by a first gateway (11), the method according to claim 4 implemented by a second gateway (12A), the second gateway being of class B and being equipped with synchronization means and the method according to claim 3 implemented implemented by a server (10).
    [0007]
    7) A method according to claim 6, characterized in that the frame comprising the request for synchronization assistance comprises a unique identifier allowing the server (10) to determine which gateway has made the request for synchronization assistance.
    [0008]
    8) Method according to claim 6 or 7, characterized in that the sub-period used to transmit a synchronization frame is determined by the first gateway and the information representative of a response to the request for synchronization help include a information representative of said sub-period.
    [0009]
    9) Method according to claim 6 or 7, characterized in that the sub-period used to transmit a synchronization frame is determined by the server (10) and the frame comprising the request for synchronization assistance comprises information representative of said subperiod.
    [0010]
    10) Method according to any one of claims 6 to 9, characterized in that said method is implemented for a predetermined duration.
    [0011]
    11) Method according to any one of claims 6 to 10, characterized in that a plurality of synchronization frames are transmitted with a predetermined periodicity.
    [0012]
    12) Method according to any one of claims 6 to 11, characterized in that when the sub-period used to transmit the synchronization frame coincides with a sub-period allocated to the second gateway for other communications, the server ( 10) designates, temporarily or permanently, another class B gateway of said network (1), equipped with synchronization means, for transmitting at least one synchronization frame to the first gateway.
    [0013]
    13) Method according to any one of claims 6 to 12, characterized in that, prior to the transmission of the frame comprising the request for assistance with the synchronization, the first gateway (11) transmits to the server (10) a requesting assistance with the preliminary synchronization using a direct communication link with the server (10), triggering a server (10) implementing a preprocessing procedure allowing the server (10) to determine if may allow the first gateway to transmit the frame including the synchronization help request.
    [0014]
    14) Method according to any one of claims 6 to 12, characterized in that, prior to the transmission of the frame including the synchronization assistance request, the server 10 sends a request to the first gateway requesting the first gateway to transmit a frame including a request for synchronization assistance.
    [0015]
    15) Method according to any one of claims 6 to 14, characterized in that the information representative of a response to the synchronization assistance request comprises information allowing a plurality of gateways, including the first gateway, to determining at least one next instant of transmission of a beacon by each class B gateway of said network (1) and of transmitting a beacon at each next determined instant of transmission.
    [0016]
    16) Method according to any one of the preceding claims, characterized in that the network (1) is a LoRa network.
    [0017]
    17) Gateway device (11) comprising means for implementing the method according to one of claims 1 to 3.
    [0018]
    18) Device of the gateway type (12A) comprising means for implementing the method according to claim 5.
    [0019]
    19) Server-type device (10) comprising means for implementing the method according to claim 4.
    [0020]
    20) System comprising at least one device according to claim 16, at least one device according to claim 17 and a device according to claim 18.
    类似技术:
    公开号 | 公开日 | 专利标题
    EP3409054B1|2020-02-26|Synchronization method for a node in a cellular network
    JP6062469B2|2017-01-18|Method and apparatus for supporting location services via a general location session
    FR3044198A1|2017-05-26|METHOD FOR CONFIGURING A GATEWAY
    JP4635615B2|2011-02-23|Information processing apparatus, system, data synchronization method, and program
    EP3146734B1|2019-10-23|Method for managing speaking turns over a communication channel in the context of simplex calls
    EP3238384A1|2017-11-01|Method of transmitting data between a server and an electronic unit for control of a home automation installation
    EP2901617B1|2016-11-16|Communication method, communication management method, associated nodes and devices
    EP3777308B1|2021-07-07|Communication method
    EP3510713A1|2019-07-17|Method for detecting retransmission of a frame
    EP2854467B1|2016-03-23|System and method for sharing distributed capacity in an ad-hoc network
    WO2019185552A1|2019-10-03|Communication method
    EP2341728A1|2011-07-06|System and method for controlling communications in a mobile ad-hoc network
    EP3395045B1|2021-06-09|Method for determining a temporal reference and/or at least one spatial reference in a communication system
    EP3588827B1|2021-04-28|Method for quick acknowledgement of a frame
    WO2018011517A1|2018-01-18|Method for assigning a terminal to an access network of a wireless communication system
    WO2017187026A1|2017-11-02|Detection and communication system for mobile devices.
    EP3348090B1|2019-11-06|Method and device for establishing and maintaining internet access through the use of a wireless communication protocol in a local computer network from a mobile client station
    EP3085185B1|2019-07-10|Asynchronous communication method and system
    EP3348043B1|2020-03-18|Method and system for establishing internet access by using a wireless communication protocol in a local computer network from a mobile client station
    EP3391695B1|2021-03-17|Method for managing the operation of a connected object
    WO2011023904A1|2011-03-03|Method for the geolocated broadcasting of content in a telecommunication network
    EP2494764A1|2012-09-05|Method for authenticating a mobile communication terminal for providing data service, and related service-providing system and terminal
    EP3360293A1|2018-08-15|Means for managing access to data
    WO2011023881A1|2011-03-03|Technique for evaluating the collaboration among nodes of a communication network
    FR3029060A1|2016-05-27|METHOD OF COMMUNICATING DATA BETWEEN A RADIO EQUIPMENT AND A NETWORK ACCESS GATEWAY
    同族专利:
    公开号 | 公开日
    WO2017129447A1|2017-08-03|
    CN108605301B|2020-12-15|
    CN108605301A|2018-09-28|
    US20190053180A1|2019-02-14|
    EP3409054B1|2020-02-26|
    US10470146B2|2019-11-05|
    FR3047384B1|2018-11-23|
    BR112018015070A2|2018-12-11|
    EP3409054A1|2018-12-05|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US20050281247A1|2004-06-21|2005-12-22|Samsung Electronics Co., Ltd.|Method and system for acquiring time sync between access points in a broadband wireless access communication system|
    WO2012158578A1|2011-05-13|2012-11-22|Qualcomm Incorporated|Method and apparatus for time and frequency tracking in clustered femtocell deployments|
    CN104394586A|2014-11-28|2015-03-04|广州杰赛科技股份有限公司|Synchronization method and system of miniature base station and clock server|
    US7230908B2|2000-07-24|2007-06-12|Viasat, Inc.|Dynamic link assignment in a communication system|
    CN101132222B|2006-08-22|2011-02-16|上海贝尔阿尔卡特股份有限公司|Gateway equipment, communication network and synchronization method|
    EP2273717B1|2008-04-24|2016-05-25|Fujitsu Limited|Node device and program|
    US9668230B2|2009-11-10|2017-05-30|Avago Technologies General Ip Pte. Ltd.|Security integration between a wireless and a wired network using a wireless gateway proxy|
    CN102014479B|2009-12-31|2013-11-06|电信科学技术研究院|HeNB synchronization method, system and device|
    CN102056285A|2011-01-18|2011-05-11|大唐移动通信设备有限公司|Clock synchronization method, system and equipment|
    CN102781080B|2012-07-05|2015-05-06|上海大学|Power self-adaptive method of network access and operation of nodes of wireless sensor network|
    US9264161B2|2013-12-10|2016-02-16|Life Safety Distribution Ag|Wireless fire system with idle mode and gateway redundancy|
    US9706923B2|2014-02-25|2017-07-18|General Electric Company|System and method for adaptive interference mitigation in wireless sensor network|
    EP2975814B1|2014-07-18|2020-09-02|Semtech Corporation|Chirp Signal Processor|
    BE1023514B1|2015-10-05|2017-04-12|Henri Crohas|Method and device for wireless communication|
    CN105307249B|2015-11-09|2018-12-25|深圳市银河风云网络系统股份有限公司|Low-consumption wireless Transmission system and its transmission method|CN107682938A|2017-03-20|2018-02-09|上海贝壳供应链管理有限公司|A kind of communication system based on LORA from group agreement|
    EP3603027A1|2017-03-31|2020-02-05|Convida Wireless, LLC|Interworking lpwan end nodes in mobile operator network|
    CN109429325B|2017-08-24|2021-03-26|阿里巴巴集团控股有限公司|Data transmission method, device, base station and server|
    CN107548103B|2017-09-28|2021-07-23|新华三技术有限公司|Data forwarding method and device|
    US10455640B2|2017-12-30|2019-10-22|Intel Corporation|IoT networking extension with bi-directional packet relay|
    TWI674779B|2018-05-09|2019-10-11|奇邑科技股份有限公司|Wireless communication system, communication method and a portable transceiver device|
    CN110557184B|2018-05-31|2021-11-16|阿里巴巴集团控股有限公司|Communication method and device based on relay equipment and communication method and device between terminal and base station|
    CN108934063B|2018-09-29|2021-02-02|佛山市顺德区中山大学研究院|Lora terminal energy-saving method based on binary search time slot randomization communication mechanism|
    FR3087081A1|2018-10-09|2020-04-10|Sagemcom Energy & Telecom Sas|COMMUNICATION PROCESS|
    CN109587023A|2018-12-28|2019-04-05|万能|A kind of LoRa ad hoc network method and system|
    CN109617744B|2019-01-10|2020-04-28|电子科技大学|LoRa minimum PingSlot number prediction method|
    US10904949B2|2019-03-21|2021-01-26|Hall Labs Llc|Bridge for wireless communication|
    CN111757273A|2019-03-29|2020-10-09|阿里巴巴集团控股有限公司|Multicast communication method, system, multicast application server and terminal of communication network|
    CN111988774A|2019-05-24|2020-11-24|阿里巴巴集团控股有限公司|Communication method and device for beacon frame in communication network|
    EP3840454A1|2019-12-17|2021-06-23|Koninklijke KPN N.V.|Computer-implemented method and product for determining a gateway beacon transmission scheme in a low power wide area network|
    法律状态:
    2016-12-20| PLFP| Fee payment|Year of fee payment: 2 |
    2017-08-04| PLSC| Search report ready|Effective date: 20170804 |
    2017-12-21| PLFP| Fee payment|Year of fee payment: 3 |
    2019-12-19| PLFP| Fee payment|Year of fee payment: 5 |
    2020-12-17| PLFP| Fee payment|Year of fee payment: 6 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1650688A|FR3047384B1|2016-01-28|2016-01-28|METHOD FOR SYNCHRONIZING A GATEWAY IN A LORA NETWORK|
    FR1650688|2016-01-28|FR1650688A| FR3047384B1|2016-01-28|2016-01-28|METHOD FOR SYNCHRONIZING A GATEWAY IN A LORA NETWORK|
    PCT/EP2017/050896| WO2017129447A1|2016-01-28|2017-01-17|Synchronisation method for a node in a cellular network|
    CN201780008553.3A| CN108605301B|2016-01-28|2017-01-17|Synchronization method for nodes in a cellular network|
    EP17700461.1A| EP3409054B1|2016-01-28|2017-01-17|Synchronization method for a node in a cellular network|
    BR112018015070-3A| BR112018015070A2|2016-01-28|2017-01-17|synchronization method for a node in a cellular network|
    US16/070,431| US10470146B2|2016-01-28|2017-01-17|Method for synchronising a gateway in a LoRa network|
    [返回顶部]